home *** CD-ROM | disk | FTP | other *** search
/ Light ROM 4 / Light ROM 4 - Disc 1.iso / text / net_news / 1994 / 3.doc / text0206.txt < prev    next >
Encoding:
Text File  |  1995-03-24  |  3.0 KB  |  66 lines
  1. In article <3co6ij$qj4@news.eecs.uic.edu>, bdupras@bert.eecs.uic.edu (Brian
  2. Dupras) wrote:
  3.  
  4. > Frank Aalbers (frank@nbre.nfe.be) wrote:
  5. > 
  6. > > Does someby knows if there is going to be software included with V4.0 to
  7. > > transfer AMIGA-scenes to other platforms and vica-verca ?
  8. > 
  9. > The scenes are supposed to be cross platform since they're just ASCII
  10. > text files.  Rumor has it that that the objects will be cross platform as
  11. > well.
  12. > 
  13. > >    ________________________________________________________________
  14. > >   |                                  |                             |
  15. > >   | Frank Aalbers                    | -PIXION- computeranimations |
  16. > >   | frank@nbre.nfe.be / 2:292/603.27 | FAX + VOICE 03/326-30-85    |
  17. > >   |                                  | Deurne Belgium              |
  18. > >   |__________________________________|_____________________________|
  19.  
  20.  
  21. This is correct according to what Lee has been saying.
  22.  
  23. The problem will be with "PLUG IN's" which will allow you to
  24. do things like create a solar system from your collection of
  25. planet objects. LW proper doesn't know how to calculate orbital
  26. dynamics for the frames between key frames. This would be the
  27. job of a "PLUG IN" application which would most likely extend
  28. the object file to include orbital dynamic data. I don't know
  29. exactly how NewTek will support extra data, but it doesn't really
  30. matter cuz the extra data is needed and has to be stored somewhere.
  31.  
  32.  
  33. If this "PLUG IN" module only exists on an Amiga, then when you
  34. move the scene to a Win NT machine it would not know how to
  35. calculate the in-between frames and it wouldn't know what to do
  36. with the extra data in the object file or wherever it is stored.
  37.  
  38. A way around this would be to calculate the position of everything
  39. in a frame on the host machine and then send that frame's setup to 
  40. the rendering engine for "rendering".  This approach would clearly
  41. have to be supported from inside LW. With the option ON, Lightwave
  42. would calculate the frame setup and then save it to a user specified 
  43. location. It then would be up to the user to have a "sentry" or 
  44. "daemon" that would make the file available to a rendering engine or 
  45. render farm over whatever network the user wants to use.
  46.  
  47. Today, lightwave doesn't care what is done with the file after it is
  48. rendered. (it could go into a PAR anim or to an Abekas, LW knows not).
  49. Similarly, I think LW will have to split off the rendering step as well 
  50. if that is possible, and let the user decide where the current frame 
  51. will be rendered and what type of machine will do the render.
  52.  
  53. I.E. the "frame data" must be cross platform compatible not the
  54. motion data (between frame).
  55.  
  56. This sounds too easy; there's gotta be a catch ;-}
  57.  
  58.   
  59. <<<<=======================================================================
  60.     Richard Norman                              norman@eisner.decus.org
  61.       AMIGA --- Amazing Multitasking Interactive Graphics & Animation 
  62. =======================================================================>>>>
  63.  
  64.  
  65.  
  66.